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TITLE OF THE INVENTION 
EXTENSIBLE SYSTEM FOR BUILDING AND EVALUATING CREDENTIALS 



CROSS REFERENCE TO RELATED APPLICATIONS 
N/A 

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR 
DEVELOPMENT 
N/A 

BACKGROUND OF THE INVENTION 

The present invention relates to systems and techniques 
for authenticating and authorizing users of computers and 
other computerized devices connected to a network. 

Computers and other computerized devices are frequently 
used in networked configurations. Computer networks 

advantageously allow multiple users operating respective 
computers to share information, access services provided by 
other devices connected to the network, and/or share 
hardware resources such as mass storage systems, printers, 
and facsimile machines. 

For example, computers may be connected to a local area 
network (LAN) , which generally allows a relatively small 
number of computers in a limited area to share information 
and access services/resources. Computers that are connected 
to a common LAN typically belong to the same group. 

Further, computers may be connected to respective 
LANs, thereby defining multiple groups of computers. These 
LANs may also be linked together by way of, e.g., a wide 
area network (WAN) and/or the Internet, thereby allowing 
some or all of the relatively small number of computers in 
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each group to share information and access 
services/resources . 

Computers and other computerized devices, whether they 
are connected to a LAN and/or part of a larger WAN, also 
frequently have access to external networks, e.g., the 
Internet. For example, in a so-called "open" network 
configuration, all computers connected to an internal 
network typically have direct access to the external 
network. Alternatively, a specialized computer, sometimes 
called a "gateway" computer, may be interposed between the 
internal network and the external network, thereby requiring 
the computers connected to the internal network to access 
the external network indirectly by way of the gateway 
computer . 

Although computer networks provide numerous advantages 
in facilitating the sharing of information and the accessing 
of services/resources between multiple users, computer 
networks have drawbacks in that they are subject to security 
breaches. For example, computers assigned to respective 
groups often share common access privileges relative to, 
e.g., specific files, directories, databases, web pages, and 
other services/resources. It is therefore desirable to 
authenticate users to ensure that, e.g., the users belong to 
particular groups and therefore have the requisite 
privileges for accessing the desired service/resource. In 
this way, unauthorized users can be prevented from accessing 
restricted information, services, and/or resources on the 
computer network; and, the security of the restricted 
information, services, and/or resources can be maintained. 



Not only is it desirable to authenticate users to 
ensure that the users have the requisite access privileges, 
but it is also desirable to perform user authentication to 
ensure that any message and/or data transmitted by a user in 
5 fact originated with that user, and was not intentionally or 
inadvertently modified during the transmission through the 
network to its destination. In this way, the integrity of 
any message/data transmissions on the computer network can 
be maintained. 

10 User authentication is conventionally performed on a 

computer network as follows. First, a user operating a 
client computer initiates a connection with a server 
computer via the network, e.g., for accessing a 
service/resource provided by the server computer. 

15 Next, if access to the service provided by the server 

computer is restricted, then, instead of immediately 
accepting the connection, the server computer transmits a 
message to the client computer that includes information 
about what the client computer must do to authenticate the 

20 user. 

For example, a secure channel for transmitting 
messages /data between the client and server computers over 
the network may be set up using the well-known Secure Socket 
Layer (SSL) protocol. Specifically, the client and server 
25 computers execute SSL routines, which set up the secure 
channel through the network using, e.g., public-private key 
pair cryptography techniques for encrypting/decrypting 
transmitted messages/data and digital signatures for user 
authentication. 

- 3 - 




More specifically, using the SSL protocol, the server 
computer typically transmits a message to the client 
computer that includes a request for a certification path 
(i.e., a "certpath") from the server computer to the client 
5 computer. For example, the message transmitted by the 
server computer may include a certificate request message, 
which typically includes a list of acceptable certificate 
types and a list of acceptable certificate authorities. 

Accordingly, in order to authenticate the user, the 

10 client computer transmits a message to the server computer 
that includes a certpath from the server computer to the 
client computer that conforms to the lists of acceptable 
certificate types and authorities. That certpath from the 
server computer to the client computer is regarded as the 

15 client computer's "credentials" (i.e., "certpath" 
credentials) to the server computer. 

Finally, the server computer evaluates the credentials 
transmitted by the client computer; and, if they satisfy the 
certificate request message, then the user is properly 

20 authenticated and authorized, and the server computer 
subsequently provides the requested service/resource to the 
client computer. 

However, such conventional techniques for providing 
user authentication in computer networks have drawbacks. 

25 For example, the SSL protocol generally requires the client 
computer to build certpath credentials, thereby providing an 
indication of the certpath from the server computer to the 
client computer for authenticating the user. But, in some 
applications, the client computer may be incapable of 

30 building the required certpath credentials, even though it 
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might be capable of building other types of credentials. 
Similarly, the server computer may be incapable of 
evaluating such certpath credentials, even though it might 
be capable of evaluating other types of credentials. 
Further, because the SSL protocol generally deals only with 
certpath credentials, in some applications, it may be 
incapable of providing a full set of credentials from the 
client computer to the server computer, thereby providing a 
definitive indicati on of the access privileges of the user. 

In addition, even though client computers normally 
request access to services/resources from server computers 
via a network, and the server computers normally provide the 
requested information and/or services to the client 
computers, in some applications, the server computers may at 
least temporarily take on the role of clients and/or the 
client computers may at least temporarily take on the role 
of servers. However, these computers using conventional 
techniques such as the SSL protocol may be incapable of 
building and/or evaluating all of the different types of 
credentials required for authenticating users in their dual 
roles as clients and servers. 

It would therefore be desirable to have improved 
systems and techniques for authenticating and authorizing 
users of computers and other computerized devices connected 
to a network that are extensible to permit incorporation of 
new and/or different types of credentials, credential 
builders, and/or credential evaluators. It would also be 
desirable to have improved systems and techniques for 
authenticating and authorizing users that provide for secure 
communications between any computers connected to a network, 



thereby allowing any computer on the network to request 
credentials from any other computer accessible via the 
network for user authentication/authorization. 



5 BRIEF SUMMARY OF THE INVENTION 

Consistent with the present invention a method and 
apparatus are disclosed for authenticating and authorizing a 
user of a device connected to a network. Such user 
authentication/authorization is accomplished by way of 
10 extensible resources for building and evaluating 
credentials . 

In one embodiment, a plurality of credential 
descriptors is generated for the user's device, which is a 
client computer. These credential descriptors are then 

15 provided to a first master credential builder, which is 
included in either the client computer or a server computer. 
Credentials are then built corresponding to at least one of 
the credential descriptors using the first master credential 
builder. Next, in the event that there is at least one 

20 credential remaining to be built, at least one credential 
descriptor corresponding thereto is provided to a second 
master credential builder, which is included in a computer 
different from that which includes the first master 
credential builder. Credentials are then built 

25 corresponding to at least one of these credential 
descriptors using the second master credential builder. In 
the event that there are no credentials remaining to be 
built, the credentials built by the first and second master 
credential builders are then provided to a master credential 

30 evaluator, which is included in either the computer with the 
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first master credential builder or the computer with the 
second master credential builder. Next, the master 

credential evaluator evaluates the built credentials, 
thereby determining whether the built credentials satisfy 
the original set of credential descriptors. In another 
embodiment, a set of credential descriptors corresponding to 
credentials remaining to be built are provided to a third 
master credential builder, which is included in a computer 
different from the client and server computer. 

In the foregoing manner, a negotiated dialogue can be 
initiated and maintained between a plurality of computers 
over the network for building and evaluating credentials for 
use in authenticating a user. 

The first and second master credential builders may be 
modified by adding (removing) credential builders to (from) 
the first and second master credential builders. Similarly, 
the master credential evaluator may be modified by adding 
(removing) credential evaluators to (from) the master 
credential evaluator. 

In the foregoing manner, the first and second master 
credential builders and the master credential evaluator, 
which are modifiable resources, are adapted to suit specific 
requirements for authenticating and authorizing the user. 

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 
The invention will be more fully understood by 
reference to the following Detailed Description of the 
Invention in conjunction with the Drawing of which: 

Fig. 1 is a block diagram depicting a computer network 
operative in a manner consistent with the present invention; 



Fig. 2 is a software flow diagram for a representative 
computer connected to the computer network of Fig. 1, 
operative in a manner consistent with the present invention; 

Fig. 3 is a flow diagram depicting an exemplary method 
5 of operation for the master credential builder depicted in 
Fig. 2; and 

Fig. 4 is a flow diagram depicting an exemplary method 
of operation for the master credential evaluator depicted in 
Fig. 2. 

10 

DETAILED DESCRIPTION OF THE INVENTION 
Fig. 1 depicts an illustrative embodiment of a computer 
network 100 that is operative in a manner consistent with 
the present invention. Specifically, the computer network 

15 100 includes a plurality of client computers, e.g., client 
computers 110, 112, 114, and 115 operatively connected to a 
network 102. In this illustrative embodiment, the client 
computers 110, 112, and 114 are regarded as belonging to the 
same Group A (see Fig. 1) . 

20 The network 102 allows human operators ("users"; not 

shown) of the client computers 110, 112, 114, and 115 to 
share and/or exchange information, and/or share hardware 
resources (not shown) connected to the network 102 such as 
mass storage devices, printers, and facsimile machines. 

25 Those of ordinary skill in the art will appreciate that the 
term "users" may further comprise processes executing on the 
client computers 110, 112, 114, and 115, data processing 
agents, or other computer resources in addition to human 
operators . 




The computer network 100 further includes at least one 
server computer, e.g., a server computer 120, operatively 
connected to the network 102, thereby allowing the users of 
the client computers 110, 112, 114, and 115 to access 
5 services/resources provided by the server computer 120. 
Still further, the computer network 100 includes at least 
one server computer, e.g., a server computer 130, connected 
to a network 104. 

The networks 102 and 104 may comprise a Local Area 

10 Network (LAN) , a Wide Area Network (WAN), the Internet, or 
any other network suitable for authenticating and 
authorizing users of computers and other computerized 
devices connected to the networks 102 and 104. Further, 
respective segments of the networks 102 and 104 may comprise 

15 lengths of contiguous wire, optical fiber, or coaxial cable. 
Alternatively, the network 102 and/or the network 104 may 
comprise a wireless network. 

Each of the client computers 110, 112, 114, and 115, 
and the server computers 120 and 130, includes at least one 

20 memory (not shown) such as a ROM and/or a RAM, e.g., for 
storing operating systems, application software modules, 
and/or executable scripts; and, at least one processor (not 
shown), e.g., for processing user inputs, for initiating and 
controlling connections to the networks 102 and 104, for 

25 executing applications or executable scripts, and/or for 
controlling access to services/resources. 

For example, various types of services/resources may be 
made available to the user once the requirements for user 
authentication/authorization have been satisfied. By way of 

30 example, and not limitation, a user may be permitted to pass 




through a locked doorway upon presentation of a proper 
credential (s) , may be permitted to operate prescribed 
machinery, may be permitted access to certain resources 
within a computer system such as files, directories, 
databases or any other computer resource, or may be 
permitted access to or the right to modify, a web page. In 
addition, members of one group may be provided only read 
privileges for certain computer resources while members of 
another group may be provided read/write privileges. It 
should be appreciated that once the technique for 
authenticating and authorizing users of computers and other 
computerized devices is understood, the presently described 
technique may be employed in any application in which it is 
desired to perform user authentication/authorization. 

The networks 102 and 104 are operatively linked by a 
gateway computer 140, which similarly includes at least one 
memory (not shown) and at least one processor (not shown) , 
thereby permitting the client computers 110, 112, 114, and 
115 and/or the server computer 120 connected to the network 
102 to access the server computer 130 connected to the 
network 104 by way of the gateway computer 140. 

Fig. 2 depicts a partial block diagram of a software 
configuration 200 for the computers and other computerized 
devices connected to the computer network 100. 
Specifically, the software configuration 200 includes a 
plurality of software modules such as a master credential 
builder 264 and a master credential evaluator 266, which are 
employed for authenticating users of the computers and other 
computerized devices connected to the computer network 100. 



More specifically, the master credential builder 264 
preferably includes a plurality of different software sub- 
modules, e.g., credential builders (CBs) 1 through N, and a 
remote CB 270; and, similarly, the master credential 
evaluator 266 preferably includes a plurality of different 
software sub-modules, e.g., credential evaluators (CEs) 1 
through M, wherein the value, N, may or may not be equal to 
the value, M. 

It should be appreciated that each of the client 
computers 110, 112, 114, and 115, and the server computers 
120 and 130, depicted in Fig. 1, may operatively include at 
least one software module consistent with the master 
credential builder 264 and the master credential evaluator 
2 66, and/or at least one software sub-module consistent with 
the CBs 1 through N and the CEs 1 through M, as depicted in 
Fig. 2. 

In a preferred embodiment, each of the client computers 
110, 112, 114, and 115, and the server computers 120 and 130 
include at least one software module operative in a manner 
consistent with the master credential builder 264 and the 
master credential evaluator 266. It should be noted, 
however, that each and every one of the computers 110, 112, 
114, 115, 120, and 130 need not include such software 
modules . 

Although the client computers 110, 112, 114, and 115 
and the server computers 120 and 130 preferably include 
respective master credential builders and/or respective 
master credential evaluators, it should also be noted that 
the respective master credential builders and the respective 



credential evaluators may include different software sub- 
modules, CB and CE. 

The master credential builders and/or the master 
credential evaluators included in the client computers 110, 
5 112, 114, and 115 and the server computers 120 and 130 can 
be extended by simply adding one or more CBs and one or more 
CEs to the master credential builders and the master 
credential evaluators, respectively. Conversely, CBs and 
CEs can be removed from the master credential builders and 

10 the master credential evaluators, respectively. In this 
way, the master credential builders and the master 
credential evaluators can be dynamically modified and 
adapted to suit specific user authentication requirements of 
the computer network 100. 

15 For example, CBs and CEs may be added to or removed 

from a master credential builder and a master credential 
evaluator, respectively, in response to a predetermined 
event such as a change in an access control list (ACL) for a 
requested service/resource. Such a change may result in a 

2 0 new or different credential that needs to be built and 
evaluated for users seeking to access the service/resource. 
The master credential builder and the master credential 
evaluator may therefore be modified to suit this new user 
authentication requirement by adding an appropriate CB and 

25 CE, respectively, thereto. 

Specifically, the CBs 1 through N, and the remote CB 
270, are preferably serially linked in the master credential 
builder 2 64, thereby forming a "chain" of CBs. Similarly, 
the CEs 1 through M are preferably serially linked in the 

30 master credential evaluator 266, thereby forming a chain of 
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CEs. Accordingly, depending upon the specific user 

authentication requirements of the computer network 100, the 
master credential builder 264 can be modified by adding 
(removing) one or more CBs to (from) the chain of CBs 
included therein. Similarly, the master credential 

evaluator 2 66 can be modified by adding (removing) one or 
more CEs to (from) the chain of CEs included therein. 

In addition, user authentication can be performed by 
way of a negotiated dialogue between two or more computers 
and/or computerized devices connected to the computer 
network 100 using the respective master credential builders 
and the respective master credential evaluators. 

As depicted in Fig. 2, inputs to the master credential 
builder 2 64 include a credential descriptor (CD) and a set 
of credentials (CRED) ; and, outputs of the master credential 
builder 264 include a revised CD (REVISED_CD1 ) and a set of 
built credentials (BUILT_CRED) . Further, inputs to the 
master credential evaluator 2 66 include CD and the set of 
built credentials, BUILT_CRED ; and, an output of the master 
credential evaluator 266 includes another revised CD 
(REVISED_CD2) . 

Consistent with the systems and techniques of the 
present invention, a user operating a client computer 
initiates a connection with a server computer by way of a 
computer network for accessing a particular 

service/resource. If access to that service/resource were 
restricted, then, instead of immediately providing access to 
the requested service/resource, the server computer 
generates CD, which describes the set of credentials of the 
client computer that must be built and subsequently 



evaluated for authenticating the user before allowing access 
to that particular service/resource. 

For example, a client computer's credentials to a 
server computer may include a certpath credential used by 
the server computer for obtaining the "public key" of the 
client computer; a proof-of-possession credential used by 
the server computer for confirming that the client computer 
has possession of a corresponding "private key"; a non- 
revocation of certificate credential used by the server 
computer for confirming that the client computer' s 
"certificate" has not been revoked; and/or, a group 
membership credential used by the server computer for 
confirming the client computer's membership in a particular 
group . 

It should be appreciated that the client computer' s set 
of credentials to the server computer may include types of 
credentials that are different from those listed above, and 
that new types of credentials may subsequently be defined 
and added to the client computer's set of credentials. 
Similarly, CDs corresponding to sets of credentials may take 
different forms. Accordingly, the types of credentials and 
the ways of describing those credentials for authenticating 
users of computers and computerized devices connected to the 
computer network 100 may vary in different systems and 
applications . 

In the preferred embodiment, both the client and server 
computers include respective master credential builders 
consistent with the master credential builder 264 for 
building the set of credentials corresponding to CD. 



Further, because the respective master credential 
builders for the client and server computers may be modified 
to include different CB sub-modules, the client and server 
computers preferably build only those credentials of the 
5 required set of credentials that they are both willing to 
build and capable of building. This will be described in 
greater detail below in reference to illustrative examples 
for authenticating and authorizing users. 

In the presently disclosed embodiment, the server 
10 computer first builds those credentials of the required set 
of credentials that it is both willing to build and capable 
of building, before the client computer builds any 
credentials . 

Specifically, CD and the set of credentials (CRED) are 
15 provided to the sub-module, CB1, of the master credential 
builder for the server computer. As mentioned above, CD 
describes the set of credentials of the client computer that 
must be built for authenticating the user. Further, the set 
of credentials, CRED, at the input of CBl is a set of 
2 0 credentials that have already been built, if any. For 
example, the master credential builder for the server 
computer may have access to a memory included in the server 
computer for storing useful built credentials. Accordingly, 
the set of credentials, CRED, provided to CBl may either 
2 5 include a set of built credentials or it may be empty. 

As mentioned above, the master credential builder 264 
preferably includes a plurality of different CB sub-modules, 
CBl through CBN. Specifically, each CB sub-module, CBl 
through CBN, is used for building a specific type of 
30 credential. Accordingly, if the sub-module CBl were capable 
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of building one of the types of credentials described by CD 
provided at its input, then it builds that type of 
credential and then provides a revised credential 
descriptor, CDl, and a revised set of built credentials, 
CREDl , to the sub-module CB2, which is the next credential 
builder in the chain of CBs . 

Specifically, CDl is a credential descriptor describing 
a set of credentials that remains to be built. For example, 
CDl describes all of the types of credentials described by 
CD, except for the type of credential built by the sub- 
module CB1, if any. Accordingly, if the sub-module CB1 were 
incapable of building any of the types of credentials 
described by CD, then CDl would be identical to CD. 

Further, CREDl is a revised set of built credentials 
that not only includes all of the credentials of CRED, but 
also includes the credential built by the sub-module CB1, if 
any. If the sub-module CBl were incapable of building any 
of the types of credentials described by CD, then CREDl 
would be identical to CRED. 

Similarly, the sub-modules CB2 through CBN of the 
master credential builder 264 take a credential descriptor 
and a set of built credentials provided at their respective 
inputs, build any type of credential described by the 
credential descriptor that they are capable of building, and 
provide a revised credential descriptor and a revised set of 
built credentials at their respective outputs. 

Specifically, CD2 describes all of the types of 
credentials described by CDl, except for the type of 
credential built by the sub-module CB2, if any. Further, 
CRED2 is a set of built credentials that not only includes 



all of the credentials of CREDl, but also includes the 
credential built by the sub-module CB2, if any. 

Similarly, CDN describes all of the types of 
credentials described by the credential descriptor at the 
input of the sub-module CBN, except for the type of 
credential built by the sub-module CBN, if any. Further, 
CREDN is a set of built credentials that not only includes 
all of the credentials of the set of credentials at the 
input of the sub-module CBN, but also includes the 
credential built by the sub-module CBN, if any. 

As depicted in Fig. 2, the sub-module CBN provides CDN 
and CREDN to the remote CB 27 0, which is a software sub- 
module used in communicating with a master credential 
builder for another computer or computerized device 
connected to the computer network 100. For example, that 
other master credential builder may be included in the 
client computer for which the set of credentials is 
currently being built. Alternatively, that master 

credential builder may be included in a computer or 
computerized device other than the client and server. In 
either case, the remote CB 270 enables a negotiated dialogue 
to be performed between the server computer and another 
computer or computerized device in the computer network 100 
to build a set of credentials for authenticating the user of 
the client computer. 

In this illustrative embodiment, the remote CB 27 0 is 
used in communicating with the respective master credential 
builder of the client computer. Accordingly, using the 
remote CB 27 0, the server computer forwards CDN and CREDN to 
the client computer by way of the computer network 100 for 
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input to the respective master credential builder of the 
client computer. 

The master credential builder of the client computer 
then operates on CDN and CREDN in a manner similar to that 
described above for the server computer's master credential 
builder. Specifically, the client computer provides CDN and 
CREDN to the first sub-module CB in the chain of CBs 
included in its master credential builder, the chain of CBs 
successively builds the types of credentials that each sub- 
module CB in the chain is capable of building while 
successively outputting revised CDs and revised sets of 
built credentials, and then the client computer transmits a 
revised credential descriptor, CDN' , and a revised set of 
built credentials, CREDN', to the server computer for 
subsequently inputting CDN' and CREDN' into the remote CB 
270 (see Fig. 2) . 

As depicted in Fig. 2, CDN' and CREDN' can be 
optionally looped back from the outputs of the remote CB 270 
to the inputs of the sub-module CBl for processing CDN' and 
CREDN' through the chain of CBs 1 through N of the master 
credential builder 2 64, thereby ensuring that CBl through 
CBN have built all of the different types of credentials 
described by CDN' that they are capable of building. 
Similarly, the remote CB 270 can optionally be used again 
for providing a revised CD and a revised set of built 
credentials to the master credential builder of the client 
computer or other computerized device for additional 
processing. Finally, if it is determined that additional 
processing no longer results in further revisions to CD and 
the set of built credentials, then the credential descriptor 
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and the set of built credentials are provided at the output 
of the master credential builder 2 64 as the REVISED_CD1 and 
the BUILT_CRED, respectively. 

It should be appreciated that if the master credential 
5 builder of the server computer and/or the master credential 
builder of the client computer or other computerized device 
is capable of building all of the credentials required for 
authenticating the user of the client computer, then the 
REVISED_CD1 is empty and the BUILT_CRED includes a full set 
10 of built credentials corresponding to the credential 
descriptions included in CD. 

In this illustrative embodiment, the set of built 
credentials, BUILT_CRED, is evaluated for determining 
whether BUILT_CRED includes all of the credentials 
15 corresponding to CD. The BUILT_CRED is preferably evaluated 
using the master credential evaluator for the server 
computer, which is consistent with the master credential 
evaluator 266. 

Specifically, CD and the set of built credentials, 
2 0 BUILT_CRED, are provided to the sub-module CEl of the master 
credential evaluator. As mentioned above, the master 
credential evaluator 266 preferably includes a plurality of 
different CE sub-modules, CEl through CEN . More 
specifically, each sub-module CEl through CEN is used for 
25 evaluating a specific type of credential. Accordingly, if 
the sub-module CEl is capable of evaluating one of the types 
of credentials included in the set of built credentials, 
BUILT_CRED, then it evaluates that type of credential and 
provides a revised CD, i.e., CD1' , and the unchanged 
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BUILT_CRED to the sub-module CE2, which is the next 
credential evaluator in the chain of CEs. 

Specifically, CDl' is a credential descriptor 
describing a set of credentials that remains to be 
evaluated. For example, CDl' describes all of the types of 
credentials described by CD, except for the type of 
credential successfully evaluated by the sub-module CE1, if 
any. Accordingly, if the sub-module CE1 were incapable of 
successfully evaluating any of the types of credentials 
included in BUILT_CRED, then CDl' would be identical to the 
CD. 

Similarly, the sub-modules CE2 through CEM of the 
master credential evaluator 266 take a credential descriptor 
and the set of built credentials, BUILT_CRED , provided at 
their respective inputs, evaluate any type of credential 
included in BUILT_CRED that they are capable of evaluating, 
and then provide a revised CD and the unchanged BUILT_CRED 
at their respective outputs. 

Specifically, CD2 ' describes all of the types of 
credentials described by CDl' , except for the type of 
credential successfully evaluated by the sub-module CE2, if 
any. Similarly, CD3' describes all of the types of 
credentials described by CD2' , except for the type of 
credential successfully evaluated by the sub-module CE3, if 
any; and, CDM' describes all of the types of credentials 
described by the credential descriptor at its input, except 
for the type of credential successfully evaluated by the 
sub-module CEM, if any. 

As depicted in Fig. 2, CDM' can be optionally looped 
back from the output of the sub-module CEM to the input of 



the sub-module CE1 for processing CDM' through the chain of 
CEs 1 through M of the master credential evaluator 2 66, 
thereby ensuring that CE1 through CEM have evaluated all of 
the different types of credentials described by CDM' that 
they are capable of evaluating. Finally, if it is 

determined that additional processing no longer results in 
further revisions to CDM' , then CDM' is provided at the 
output of the master credential evaluator 2 66 as 
REVISED_CD2. 

It should be appreciated that if (1) the master 
credential evaluator 266 were capable of successfully 
evaluating all of the credentials in the set of built 
credentials, BUILT_CRED, and (2) BUILT_CRED included 
credentials corresponding to each credential description 
included in CD, then the REVISED_CD2 would be empty. In the 
preferred embodiment, the master credential evaluator is 
modified to include all of the sub-modules CE1 through CEM 
that are required for evaluating the credentials described 
in CD. If it is determined that REVISED_CD2 is empty, then 
it is concluded that the set of built credentials, 
BUILT_CRED, satisfies the credential descriptor, CD. The 
user of the client computer is therefore 
authenticated/authorized and permitted to access the desired 
service/resource provided by the server computer. 

The embodiments disclosed herein will be better 
understood with reference to the following illustrative 
examples. In a first illustrative example, a user (not 
shown) of the client computer 110 (see Fig. 1) wishes to 
obtain access to a particular service/resource provided by 
the server computer 120 (see Fig. 1) . As depicted in Fig. 



1, the client computer 110 is connected to the network 102, 
which comprises Group A. 

In order to obtain access to the particular 
service/resource provided by the server computer 120, the 
5 user of the client computer 110 transmits a message to the 
server computer 120 including a request to access that 
particular service/resource. It should be understood that 
the manner in which the client computer 110 and the server 
computer 120 transmit and receive messages is conventional. 

10 In this first illustrative example, after receiving the 

request from the client computer 110, the server computer 
120 retrieves an ACL for the requested service/resource. 
For example, the ACL may indicate that only an authorized 
user of client computer 110 in Group A is entitled to access 

15 the service/resource. The server computer 120 then converts 
the information in the ACL to a corresponding credential 
descriptor, CD. 

For example, the corresponding CD may be defined by the 
following : 

20 cert_path_CD [120-»110] AND group_membership_CD [ 110 , A] AND 

cert_path_CD[12 0^-A] AND non_revocation_CD [cert_110 ] AND 
proof_of_possession_CD [110] , 
wherein " cert_path_CD [120-»110] " is a certification path CD 
including the name of a principal (i.e., the server computer 
2 5 120) with which to start the path and the name of a target 
(i.e., the client computer 110) that should end the path; 
"group_membership_CD[110, A]" is a group membership CD 
including the name of a principal (i.e., the client computer 
110) whose group membership is to be established and the 
30 name of an issuing group (i.e., Group A) in which the 
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principal's group membership is to be established; 
"cert_path_CD[12 0-^A]" is a certification path CD including 
the name of a principal (i.e., the server computer 120) with 
which to start the path and the name of a target (i.e., 
5 Group A) that should end the path; 

w non_revocation_CD [cert_l 10 ] " is a non-revocation of 
certificate CD including an indication of a principal's 
certificate (i.e., the certificate of the client computer 
110) for which to prove non-revocation; 

10 "proof_of_possession_CD[110]" is a proof -of -possession CD 
including the name of a principal (i.e., the client computer 
110) for which to prove possession of a private key; and, 
"AND" corresponds to a standard Boolean logic operator. 

The server computer 120 builds those credentials 
15 corresponding to CD that it is both willing to build and 
capable of building using its master credential builder. 
For example, even though, in some applications, the server 
computer 120 may be capable of building all of the 
credentials that correspond to CD, it may be unwilling to 
20 build each and every credential. One possible reason for 
this is that building a particular credential may cause the 
server computer 120 to expend too much processing time. 
Accordingly, because the master credential builder is 
modifiable, the server computer 120 adds (removes) CB sub- 
25 modules to (from) the chain of CBs so that the master 
credential builder includes only those CB sub-modules that 
correspond to credentials in CD for which the server 
computer 120 is both willing to build and capable of 
building . 
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For example, the server computer 120 may be both 
willing to build and capable of building credentials 
corresponding only with the following credential 
descriptors: cert_path_CD [120-»110] and 

cert_path_CD[120-»A] . Accordingly, the server computer 120 
adds (removes) CB sub-modules to (from) the chain of CBs so 
that the master credential builder includes a certpath CB 
and a remote CB consistent with the remote CB 270. It 
should be understood that the server computer 12 0 may add 
(remove) CB sub-modules to (from) the chain of CBs as 
required at anytime during the user authentication process. 

Next, CD is provided as an input to the master 
credential builder for the server computer 120. In this 
first illustrative example, it is assumed that the set of 
credentials, CRED, is empty. 

Specifically, the server computer 120 builds a first 
credential corresponding to the credential descriptor, 
cert_path_CD [120->110] . For example, the server computer 
120 may have been provided with the certificate of the 
client computer 110 by way of a known Certificate Authority 
(CA) , and that certificate may then have been stored in the 
memory of the server computer 120. Accordingly, the 
certpath CB of the master credential builder for the server 
computer retrieves the certificate of the client computer 
110 from the memory and builds the corresponding credential, 
which may include a message indicating the public key of the 
client computer 110 and a digital signature. 

The digital signature may be conventionally generated 
by applying the above-mentioned message to a predetermined 
hash function for generating a message digest, which may 



then be encrypted with the private key of the CA to form the 
digital signature. It should be understood that various 
techniques might be used for generating the digital 
signature such as the well known Rivest, Shamir, and Adelman 
(RSA) algorithm, the El Gamal signature algorithm (ELGA85) , 
the Digital Signature Standard (DSS) algorithm or any other 
suitable algorithm for generating a digital signature. 

Similarly, the server computer 120 builds a second 
credential corresponding to the credential descriptor, 
cert_path_CD[120->A] . For example, the server computer 120 
may also have been provided with the certificate of Group A 
by way of the CA, and that certificate may also have been 
stored in the memory of the server computer 120. 
Accordingly, the certification path CB of the master 
credential builder for the server computer 12 0 retrieves the 
certificate of Group A and builds the corresponding 
credential, which may include a message indicating the 
public key of Group A and another digital signature, which 
may be generated in a manner similar to that described 
above . 

The remote CB of the master credential builder for the 
server computer 120 is then provided with a CD (e.g., CDN; 
see Fig. 2) that describes all of the credentials remaining 
to be built, and a set of built credentials (e.g., CREDN; 
see Fig. 2) that includes the credentials built by the 
certpath CB of the master credential builder for the server 
computer 120. Specifically, the credentials remaining to be 
built include the credentials corresponding to the following 
CDs: 
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group_membership_CD [110, A], non_revocation_CD [cert_110] , 

and proof_of_possession_CD [110] . 
Further, the set of built credentials include the 
credentials corresponding to the following CDs: 

cert_path_CD [120-»110] , and cert_path_CD [ 120-»A] . 

In this first illustrative example, the remote CB is 
used to communicate with a respective master credential 
builder for the client computer 110. Accordingly, using the 
remote CB, the server computer 120 transmits CDN (see Fig. 
2) , which describes all of the credentials remaining to be 
built, and the set of built credentials, CREDN (see Fig. 2), 
which includes the credentials built by the certpath CB of 
the master credential builder for the server computer 120, 
to the client computer 110 for subsequently inputting CDN 
and CREDN into the respective master credential builder of 
the client computer 110. In this way, a negotiated dialogue 
between the server computer 120 and the client computer 110 
is initiated for authenticating the user of the client 
computer 110. 

The client computer 110 then builds those credentials 
corresponding to CDN that it is both willing to build and 
capable of building using the master credential builder of 
the client computer 110. For example, the client computer 
110 preferably adds (removes) CB sub-modules to (from) the 
chain of CBs of the master credential builder of the client 
computer 110 so that the master credential builder includes 
only those CB sub-modules that correspond to the group 
membership credential, the non-revocation of certificate 
credential, and the proof-of-possession of private key 
credential. Accordingly, the client computer 110 adds 



(removes) CB sub-modules to (from) the chain of CBs of the 
master credential builder of the client computer 110 so that 
it consists of a group membership CB, a non-revocation of 
certificate CB, and a proof-of-possession of private key CB. 
It is understood that the client computer 110 may add 
(remove) CB sub-modules to (from) the chain of CBs as 
required at anytime during the user authentication process. 

Next, the CDN and the CREDN are provided as inputs to 
the master credential builder of the client computer 110, 
and the client computer 110 builds credentials corresponding 
thereto . 

Specifically, the client computer 110 builds a third 
credential corresponding to the credential descriptor, 
group_membership_CD[110, A]. For example, the client 

computer 110 may have been provided with the certificate of 
Group A by way of the CA, and that certificate may have been 
stored in a memory of the client computer 110. Accordingly, 
the group membership CB of the master credential builder for 
the client computer 110 retrieves the certificate of Group A 
from the memory and builds the corresponding credential, 
which may include a message indicating that the client 
computer 110 is a member of Group A along with an associated 
digital signature. 

The next CB in the chain of CBs, e.g., the non- 
revocation of certificate CB, is then provided with a CD 
that describes the credentials remaining to be built, and a 
set of built credentials. Specifically, the client computer 
110 builds a fourth credential corresponding to the 
credential descriptor, non_revocation_CD [cert_110] . For 
example, the client computer 110 may again have been 
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provided with the certificate of non-revocation by way of 
the CA, and that certificate may have been stored in the 
memory of the client computer 110. Accordingly, the non- 
revocation of certificate CB retrieves the certificate of 
5 non-revocation from the memory and builds the corresponding 
credential, which may include a message indicating that the 
certificate of the client computer 110 has not been revoked 
and an associated digital signature. 

Similarly, the next CB in the chain of CBs, e.g., the 

10 proof-of-possession of private key CB, is then provided with 
a CD that describes the credentials remaining to be built, 
and a set of built credentials. Specifically, the client 
computer 110 builds a fifth credential corresponding to the 
credential descriptor, proof_of_possession_CD [110] . For 

15 example, the proof-of-possession of private key CB 
transforms a random challenge, R, using the private key of 
the client computer 110, i.e., [R]no, and builds the 
corresponding credential, which may include both R and 
[R] no- 

2 0 The remote CB of the master credential builder for the 

client computer 110 is then provided with a CD that 
describes all of the credentials remaining to be built, and 
a set of built credentials. Because all of the credentials 
for authenticating the user of the client computer 110 have 

25 now been built, the CD provided to the remote CB is empty, 
and the set of built credentials includes the credentials 
corresponding to the cert_path_CD [120-»110] , the 
group_membership_CD[110, A], the cert_path_CD [120^>A] , the 
non_revocation_CD [cert_110] , and the 

30 proof_of_possession_CD [110] . Accordingly, the client 
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computer 110 transmits an indication of the empty CD and the 
full set of built credentials to the server computer 120 for 
subsequently inputting that data into the remote CB of the 
master credential builder for the server computer 120, 
thereby continuing the negotiated dialogue between the 
server computer 120 and the client computer 110 for 
authenticating the user of the client computer 110. 

Because, in this first illustrative example, the client 
computer 110 provides the server computer 120 with (1) the 
empty CD, thereby indicating that all of the credentials 
required for authenticating the user of the client computer 
have been built, and (2) the full set of built credentials, 
the server computer 120 provides that full set of built 
credentials (e.g., BUILT_CRED; see Fig. 2) to the input of 
the master credential evaluator for the server computer 120. 

Because the master credential evaluator is modifiable, 
the server computer 120 adds (removes) CE sub-modules to 
(from) the chain of CEs so that the master credential 
evaluator includes only those CE sub-modules that correspond 
to the credentials described by the original CD at its 
input. Accordingly, the chain of CEs includes sub-modules 
for evaluating certpath credentials, group membership 
credentials, non-revocation of certificate credentials, and 
proof-of-possession of private key credentials. It is 
understood that the server computer 120 may add (remove) CE 
sub-modules to (from) the chain of CEs as required at 
anytime during the user authentication process. 

Specifically, the master credential evaluator of the 
server computer 120 evaluates the credentials corresponding 
to the cert_path_CD [120-»110] and the cert_path_CD [ 120-»A] . 



For example, the certpath CE may apply the above-mentioned 
hash function to the message indicating the public key of 
the client computer 110 included in the certpath credential 
of the client computer 110, thereby producing a message 
5 digest related thereto. Further, the certpath CE may 
decrypt the digital signature associated with that message 
using the public key of the CA, thereby producing another 
message digest- The certpath CE may then compare the two 
(2) message digests. If neither the message nor the digital 

10 signature associated therewith have been modified, then the 
result of the comparison is that the two (2) message digests 
are the same. This indicates to a virtual certainty that 
the message was in fact generated by the CA holding the 
private key associated with the public key used to decrypt 

15 the digital signature, and that the message indicating the 
public key of the client computer 110 has not been modified. 
In this way, the integrity of the message indicating the 
public key of the client computer 110 can be maintained. 
Accordingly, the credential corresponding to the 

20 cert_path_CD[120->>110] is successfully evaluated. Further, 
the certpath CE evaluates the certpath credential for Group 
A in a similar manner. 

The next CE in the chain of CEs, e.g., the group 
membership CE, is then provided with a CD that describes the 

2 5 credentials remaining to be evaluated, and the set of built 
credentials. Specifically, the master credential evaluator 
of the server computer 120 evaluates the credential 
corresponding to the group_membership_CD [110, A], which 
includes the message indicating that the client computer 110 

30 is a member of Group A and the associated digital signature. 
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For example, the group membership CE may evaluate that 
credential in a manner similar to that described above for 
evaluating the certification path credentials. 

Further, the next CE in the chain of CEs, e.g., the 
non-revocation of certificate CE, is provided with a CD 
describing the credentials remaining to be evaluated along 
with the set of built credentials. Specifically, the master 
credential evaluator for the server computer 120 evaluates 
the credential corresponding to the 

non_revocation_CD [cert_110] , which includes the message 
indicating that the certificate of the client computer 110 
has not been revoked and the associated digital signature. 
The non-revocation of certificate CE may also evaluate that 
credential in a manner similar to that described above for 
evaluating the certpath credentials. 

Finally, the next CE in the chain of CEs, e.g., the 
proof-of -possession of private key CE, is provided with a CD 
describing the credentials remaining to be evaluated, and 
the set of built credentials. Specifically, the master 
credential evaluator for the server computer 120 evaluates 
the credential corresponding to the 

proof_of_possession_CD [110] , which includes a random 
challenge, R, and R transformed by the private key of the 
client computer 110, [RJno- For example, the proof-of- 
possession of private key CE may evaluate [R]n 0 using the 
public key of the client computer 110 for determining 
whether the result of the evaluation matches R. If so, then 
the proof-of-possession CD is successfully evaluated, and 
there are no more credentials remaining to be evaluated. 
Accordingly, the user of the client computer 110 is 
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authenticated and authorized for accessing the desired 
service/resource provided by the server computer 120, and 
access to the service/resource is limited to authenticated 
and authorized users. 
5 In a second illustrative example, the user of the 

client computer 110 wishes to obtain access to a particular 
service/resource provided by the server computer 130 (see 
Fig. 1) . As depicted in Fig. 1, the server computer 130 is 
connected to the network 104, which is coupled to the 

10 network 102 by the gateway computer 140. 

In this second illustrative example, it is assumed that 
the gateway computer 140 blocks the server computer 130 from 
obtaining the certificate of the client computer 110. The 
server computer 130 is therefore incapable of building a 

15 certpath from the server computer 130 to the client computer 
110. 

It is further assumed that the server computer 130 is 
capable of building a certpath from the server computer 130 
to the gateway computer 140; and, the client computer 110 is 

20 capable of building a certpath from the gateway computer 140 
to the client computer 110. It is still further assumed 
that the client computer 110 and the server computer 130 are 
both willing to build these certpath credentials. 

Accordingly, the CD describing credentials required for 

25 accessing the desired service/resource provided by the 
server computer 130 includes at least the credential 
descriptor, cert_path_CD [130-»110] . Further, both the 

master credential builders for the client computer 110 and 
the server computer 130 are extended, if necessary, by 

30 adding certpath CBs to their respective chains of CBs. 
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As in the first illustrative example, the server 
computer 130 builds credentials corresponding to 
cert_path_CD [130-»110] , before the client computer 110 
attempts to build credentials. Accordingly, the certpath CB 
5 of the server computer 130 builds the certpath credential 
from the server computer 130 to the gateway computer 14 0, 
which only partially satisfies the cert_path_CD [130-»110] . 

Because the credential descriptor, 

cert_path_CD [130->110] , remains to be built, the server 
10 computer 130 subsequently transmits that CD along with any 
other CDs remaining to be built, and a current set of built 
credentials including the certpath credential from the 
server computer 130, to the gateway computer 140, and to the 
client computer 110 using the remote CB of the master 
15 credential builder for the server computer 130, thereby 
initiating a negotiated dialogue between the server computer 
130 and the client computer 110 for authenticating the user 
of the client computer 110. 

Next, the client computer 110 similarly builds 
20 credentials corresponding to cert_path_CD [130-»110] . 
Accordingly, the certpath CB for the client computer 110 
builds the certpath credential from the gateway computer 14 0 
to the client computer 110, which also only partially 
satisfies the cert_path_CD [130-H10] . 
25 However, because the client computer 110 received the 

certpath credential from the server computer 130 to the 
gateway computer 140 from the server computer 130, the 
client computer 110 has a complete chain of certificates 
from the server computer 130 to the client computer 110 and 
30 can therefore build the required credential corresponding to 
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the cert_path_CD [130->110] . The client computer 110 then 
transmits that credential along with any other credential it 
is willing to build and capable of building, to the server 
computer 130 for subsequent evaluation by the master 
credential evaluator of the server computer 130. These 
credentials are then evaluated in a manner similar to that 
described in the first illustrative example. 

A method of operation of the master credential builder 
264 consistent with the present invention is illustrated by 
reference to Fig. 3. First, a CD is provided, as depicted 
in step 302, to the master credential builder 264, thereby 
describing credentials required for authenticating a user. 
Next, a set of credentials, CRED, is optionally provided, as 
depicted in step 304, to the master credential builder 264. 
CB sub-modules are then optionally added (removed) , as 
depicted in step 306, to (from) the chain of CBs included in 
the master credential builder 264 for ensuring that the 
master credential builder 264 includes CBs for building at 
least some of the credentials described in the CD provided 
in step 302. 

Next, a decision is made, as depicted in step 308, as 
to whether there are any credentials to be built. If so, 
then, using the chain of CBs, the master credential builder 
264 attempts to build, as depicted in step 310, credentials 
corresponding to credentials described in the CD provided in 
step 302. Otherwise, the master credential builder 264 
provides, as depicted in step 318, the revised CD 

(Revised_CDl) and the revised set of built credentials 

(Built_CRED) as outputs. 
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The master credential builder 264 then transmits, as 
depicted in step 312, a CDN indicating credentials that 
remain to be built, if any, and a set of built credentials, 
CREDN, to another master credential builder. Next, the 
5 master credential builder 264 receives, as depicted in step 
314, a revised CDN' indicating credentials that remain to be 
built, if any, and a revised set of built credentials, 
CREDN', from the other master credential builder. As 
depicted in step 316, a decision is then made as to whether 
10 the revised CDN' matches the credential descriptor, CDO, 
provided at the start of the chain of CBs . If not, then 
some progress has been made in building credentials to 
satisfy the CD provided in step 302; and, the method loops 
back to step 308 to determine whether there are any more 
15 credentials remaining to be built. Otherwise, it is 
concluded that no more credentials can be built to satisfy 
the CD provided in step 302, and the master credential 
builder 264 provides, as depicted in step 318, the revised 
CD (Revised_CDl) and the revised set of built credentials 
20 (Built_CRED) as outputs. 

A method of operation of the master credential 
evaluator 266 consistent with the present invention is 
illustrated by reference to Fig. 4. First, the CD is 
provided, as depicted in step 402, to the master credential 
25 evaluator 266, thereby describing credentials required for 
authenticating the user. The set of built credentials, 
Built CRED, is then provided, as depicted in step 404, to 
the master credential evaluator 266, thereby indicating the 
credentials previously built by the master credential 
30 builder 264. 
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Next, CE sub-modules are optionally added (removed) , as 
depicted in step 406, to (from) the chain of CEs included in 
the master credential evaluator 266 for ensuring that the 
master credential evaluator 266 includes CEs for evaluating 
all of the credentials described in the CD provided in step 
402. As depicted in step 408, a decision is then made as to 
whether there are any credentials to be evaluated. If so, 
then the master credential evaluator 266 attempts to 
evaluate, using the chain of CEs, as depicted in step 410, 
credentials corresponding to the set of built credentials 
provided in step 404, with reference to the credentials 
described in the CD provided in step 402. Otherwise, the 
master credential evaluator 266 provides, as depicted in 
step 414, the revised CD (Revised_CD2) as output. 

As depicted in step 412, a decision is then made as to 
whether the revised CDM' matches the credential descriptor, 
CD0', provided at the start of the chain of CEs. If not, 
then some progress has been made in evaluating the 
credentials, Built_CRED, provided in step 4 04; and, the 
method loops back to step 408 to determine whether there are 
any more credentials remaining to be evaluated. Otherwise, 
it is concluded that no more credentials can be evaluated, 
and the master credential evaluator 266 provides, as 
depicted in step 414, the revised CD {Revised_CD2 ) as 
output . 

Those of ordinary skill in the art will appreciate that 
computer programs for performing the presently described 
functions can be delivered to a computer or other 
computerized device in many forms; including, but not 
limited to: (a) information permanently stored on non- 



writable storage media (e.g., read-only memory devices 
within a computer such as ROM or CD-ROM disks readable by a 
computer I/O attachment) ; (b) information alterably stored 
on writable storage media (e.g., floppy disks, tapes, 
read/write optical media and hard drives); or, (c) 
information conveyed to a computer through a communication 
media, for example, using baseband signaling or broadband 
signaling techniques, such as over computer or telephone 
networks via a modem. 

In addition, while in this illustrative embodiment the 
functions are illustrated as being software-driven and 
executable out of a memory by a processor, the presently 
described functions may alternatively be embodied in part or 
in whole using hardware components such as custom or semi- 
custom integrated circuits including Application Specific 
Integrated Circuits (ASICs), state machines, controllers or 
other hardware components or devices, or a combination of 
hardware components and software. 

Those of ordinary skill in the art should further 
appreciate that variations to and modification of the above- 
described methods and apparatus for authenticating and 
authorizing users of computers and other computerized 
devices connected to a network may be made without departing 
from the inventive concepts disclosed herein. Accordingly, 
the present invention should be viewed as limited solely by 
the scope and spirit of the appended claims. 
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What is claimed is: 



CLAIMS 



1. A method of building credentials for a user of a device 
5 connected to a network, the method comprising the steps of: 

providing a plurality of credential descriptors to a 
first credential builder included in a first device 
connected to the network; 

attempting to build credentials corresponding to at 
10 least one of the credential descriptors using the first 
credential builder; 

providing at least one credential descriptor for which 
a corresponding credential was not built in the first 
building step to a second credential builder included in a 
15 second device connected to the network; and 

attempting to build credentials corresponding to at 
least one of the credential descriptors provided in the 
second providing step using the second credential builder. 

2 0 2. The method of claim 1 further including the steps of 

providing the credentials built using the first and 
second credential builders to a credential evaluator 
included in the first device or the second device; and 

evaluating the built credentials using the credential 
25 evaluator to determine whether the built credentials satisfy 
the plurality of credential descriptors for the device. 

3. The method of claim 1 further including the steps of 

providing the credentials built using the first and 
30 second credential builders to a credential evaluator 

- 38 - 




included in a device connected to the network that is 
different from the first and second devices; and 

evaluating the built credentials using the credential 
evaluator to determine whether the built credentials satisfy 
5 the plurality of credential descriptors for the device. 

4 . The method of claim 1 further including the steps of 

providing at least one credential descriptor for which 

a corresponding credential was not built in the second 
10 building step to the first credential builder; and 

attempting to build credentials corresponding thereto 

using the first credential builder. 

5. The method of claim 1 further including the steps of 

15 providing at least one credential descriptor for which 

a corresponding credential was not built in either the first 
or the second building step to a third credential builder 
included in a device connected to the network that is 
different from the first and second devices; and 

20 attempting to build credentials corresponding thereto 

using the third credential builder. 

6. The method of claim 1 further including the step of 
generating the plurality of credential descriptors for the 

25 device. 

7. A system used to build credentials for a user of a 
device connected to a network, comprising: 




a first credential builder operative to build 
credentials corresponding to at least one of a plurality of 
credential descriptors for the device; and 

a second credential builder operative to build 
credentials corresponding to at least another one of the 
plurality of credential descriptors for the device, 

wherein the first credential builder and the second 
credential builder are included in different devices 
connected to the network. 

8. The system of claim 7 further including a master 
credential evaluator operative to evaluate credentials built 
by the first and second credential builders. 

9. The system of claim 8 wherein the credential evaluator 
is included in the same device as the first credential 
builder or the second credential builder. 

10. The system of claim 8 wherein the credential evaluator 
is included in a device different from the devices including 
the first and second credential builders. 

11. A method of building credentials for a user of a 
device, the method comprising the steps of: 

providing a plurality of credential descriptors to a 
master credential builder that includes a plurality of 
credential builders for building a corresponding plurality 
of different types of credentials for the device; and 



attempting to build credentials corresponding to at 
least one of the credential descriptors using the master 
credential builder. 

5 12. The method of claim 11 further including the steps of 

providing the credentials built using the master 
credential builder to a master credential evaluator that 
includes a plurality of credential evaluators for evaluating 
a corresponding plurality of different types of credentials 
10 for the device; and 

evaluating the built credentials using the master 
credential evaluator to determine whether the built 
credentials satisfy the plurality of credential descriptors 
for the device. 

15 

13. The method of claim 11 further including the step of 
generating the plurality of credential descriptors for the 
device . 

20 14. Apparatus used to build credentials for a user of a 

device, comprising: 

a master credential builder for building credentials 

corresponding to at least one of a plurality of credential 

descriptors for the device, the master credential builder 
25 including a plurality of credential builders each operative 

to build a credential of a different type for the device. 

15. The apparatus of claim 14 further including a master 
credential evaluator for evaluating the credentials built by 
30 the master credential builder to determine whether the built 
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credentials satisfy the plurality of credential descriptors 
for the device, the master credential evaluator including a 
plurality of credential evaluators operative to evaluate a 
corresponding plurality of different types of credentials 
for the device. 

16. The apparatus of claim 14 further including a 
credential descriptor generator for generating the plurality 
of credential descriptors for the device. 

17. A method of building credentials for a user of a 
device, the method comprising the steps of: 

providing a plurality of credential descriptors to a 
master credential builder, the master credential builder 
including at least one credential builder; 

adding at least one different credential builder to the 
master credential builder to form a modified master 
credential builder; and 

attempting to build credentials corresponding to at 
least one of the plurality of credential descriptors using 
the modified master credential builder. 

18. The method of claim 17 further including the steps of 
providing the different credentials built by the 

modified master credential builder to a master credential 
evaluator; 

adding different credential evaluators corresponding to 
at least a portion of the different credentials to the 
master credential evaluator to form a modified master 
credential evaluator; and 
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evaluating the credentials corresponding to at least 
one of the credentials using the modified master credential 
evaluator . 

5 19. The method of claim 18 further including the step of 
removing credential evaluators that do not correspond to at 
least one of the credentials from the master credential 
evaluator . 

10 20. The method of claim 17 further including the step of 
generating the plurality of different credential descriptors 
for the device. 

21. A method of building credentials for a user of a 
15 device, the method comprising the steps of: 

providing a plurality of credential descriptors to a 
master credential builder, the master credential builder 
including a plurality of credential builders; 

removing at least one of the credential builders from 
20 the master credential builder to form a modified master 
credential builder; and 

attempting to build credentials corresponding to at 
least one of the credential descriptors using the modified 
master credential builder. 

25 

22. Apparatus used to build credentials for a user of a 
device, comprising: 

a master credential builder including a plurality of 
credential builders operative to build credentials 
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corresponding to at least one of a plurality of credential 
descriptors for the device; and 

at least one processor operative to execute first 
program code to remove at least one credential builder from 
5 the master credential builder in response to a first event, 
and second program code to add at least one credential 
builder to the master credential builder in response to a 
second event. 



10 23. The apparatus of claim 22 further including a master 
credential evaluator including a plurality of credential 
evaluators operative to evaluate credentials built by the 
master credential builder, the at least one processor being 
operative to execute third program code to remove at least 

15 one credential evaluator from the master credential 
evaluator in response to a third event, and operative to 
execute fourth program code to add at least one credential 
evaluator to the master credential evaluator in response to 
a fourth event. 

20 

24. The apparatus of claim 22 further including a 
credential descriptor generator for generating the plurality 
of credential descriptors for the device. 

25 25. A method of building credentials for a user of a 
device, the method comprising the steps of: 

providing a master credential builder having a 
credential builder for building a first type of credential; 

in response to a predetermined event, adding an 
30 additional credential builder to the master credential 




builder for building a type of credential different from the 
first type of credential to form a modified master 
credential builder; and 

attempting to build at least one credential using the 
5 modified master credential builder. 

26. Apparatus used to build credentials for a user of a 
device, comprising: 

a master credential builder having a credential builder 
10 operative to build a first type of credential; and 

a processor operative to execute program code to add at 
least one credential builder to the master credential 
builder in response to a predetermined event, the at least 
one added credential builder being operative to build a type 
15 of credential different from the first type of credential. 

27 . A computer program product including a computer 
readable medium, the computer readable medium having a 
credential builder computer program stored thereon, the 

20 credential builder computer program being for execution in a 
computer and comprising: 

program code for building credentials corresponding to 
a plurality of different credential descriptors for a 
device . 

25 

28. The computer program product of claim 27 wherein the 
computer readable medium further has a credential evaluator 
computer program stored thereon for execution in a computer, 
the credential evaluator computer program including program 
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code for evaluating credentials corresponding to a plurality 
of different credentials for the device. 



29. A computer data signal, the computer data signal 
5 including a computer program for use in building credentials 

for a device, the computer program comprising: 

program code for building credentials corresponding to 
a plurality of different credential descriptors for the 
device . 

10 

30. The computer data signal of claim 29 further including 
a computer program for use in evaluating a plurality of 
different credentials for the device. 

15 31. Apparatus used to build credentials for a user of a 
device connected to a network, comprising: 

means for generating a plurality of credential 
descriptors for the device; 

means for providing the credential descriptors to a 
20 first credential builder; 

means for building credentials corresponding to at 
least one of the credential descriptors using the first 
credential builder; 

means for providing at least one credential descriptor 
25 for which a corresponding credential was not built in the 
first building step to a second credential builder; and 

means for building credentials corresponding to at 
least one of the credential descriptors provided in the 
second providing step using the second credential builder; 
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wherein the first credential builder and the second 
credential builder are included in different devices 
connected to the network. 

5 32. A method of evaluating credentials for a user of a 
device, comprising the steps of: 

providing a plurality of credential descriptors and a 
plurality of credentials for the device to a master 
credential evaluator including a plurality of credential 
10 evaluators for evaluating a corresponding plurality of 
different types of credentials; and 

evaluating the plurality of credentials using the 
master credential evaluator to determine whether the 
plurality of credentials satisfies the plurality of 
15 credential descriptors. 

33. A method of evaluating credentials for a user of a 
device, comprising the steps of: 

providing a plurality of credential descriptors and a 
20 plurality of credentials for the device to a master 
credential evaluator including at least one credential 
evaluator; 

adding at least one credential evaluator to the master 
credential evaluator to form a modified master credential 
25 evaluator; and 

evaluating at least one of the credentials using the 
modified master credential evaluator to determine whether 
the at least one credential satisfies at least one of the 
plurality of credential descriptors. 

30 




34. A method of evaluating credentials for a user of a 
device, comprising the steps of: 

providing a plurality of credential descriptors and a 
plurality of credentials for the device to a master 
5 credential evaluator including a plurality of credential 
evaluators; 

removing at least one of the credential evaluators from 
the master credential evaluator to form a modified master 
credential evaluator; and 
10 evaluating at least one of the credentials using the 

modified master credential evaluator to determine whether 
the at least one credential satisfies at least one of the 
plurality of credential descriptors. 

15 35. A method of evaluating credentials for a user of a 
device, comprising the steps of: 

providing a master credential evaluator having a 
credential evaluator for evaluating a first type of 
credential; 

20 in response to a predetermined event, adding an 

additional credential evaluator for evaluating a type of 
credential different from the first type of credential to 
the master credential evaluator; and 

evaluating at least one credential using the master 

2 5 credential evaluator. 




ABSTRACT OF THE DISCLOSURE 
A method and apparatus for authenticating and 
authorizing a user of a device connected to a network. In 
one embodiment, a set of credential descriptors is generated 
5 that describes credentials that must be built for 
authenticating the user. The set of credential descriptors 
is provided to a first device, which includes a first master 
credential builder for building credentials corresponding to 
at least one of the credential descriptors. In the event 

10 that the first master credential builder does not build all 
of the credentials corresponding to the set of credential 
descriptors, another set of credential descriptors is 
provided to a second device, which includes a second master 
credential builder for building at least one credential 

15 remaining to be built. This process continues until all 
credentials have been built or a determination is made that 
they cannot be built. After all credentials have been 
built, the credentials are provided to a master credential 
evaluator, which may be included in the first device, the 

20 second device, or another device. If the master credential 
evaluator successfully evaluates the built credentials, then 
user authentication is completed. Advantageously, 
credential builders and credential evaluators can be added 
to or removed from the master credential builders and the 

25 master credential evaluator, respectively, to allow dynamic 
modification of the master credential builders and the 
master credential evaluator to suit specific and changing 
requirements for user authentication/authorization. 

222824-1 
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